1. Prior Art
In “conventional” telephony mode (using the public switched telephone network (PSTN)), telephony operators establish bilateral agreements to extend the global coverage of the telephone service. The level of coverage achieved depends essentially on the number of agreements made. In outline, it can be considered that two categories of telecommunications operator are in existence: local and/or national operators, and global operators. The major global operators make a large number of agreements and can thus reach most existing destinations. Local operators make only a small number of agreements, including only one or two with major operators. Thus, a incumbent national operator in a developing country will make agreements with other national operators and one or two agreements with global operators in order to deliver calls to the rest of the world.
At present, most operators are migrating their PSTN networks to solutions and infrastructures that are based on the IP protocol. To accompany the deployment of VoIP services, the Internet engineering task force (IETF) has undertaken a large amount of standardization work. Several protocols have been specified, amongst which mention can be made of session initiation protocol (SIP), session description protocol (SDP), real-time transfer protocol (RTP), real-time transfer control protocol (RTCP), multimedia gateway control protocol (MGCP), session announcement protocol (SAP), and telephony routing over IP (TRIP, RFC3219). These protocols satisfy different requirements and in particular they incorporate call signaling and control, the exchange and control of media streams, and the exchange of call routing information.
TRIP enables interconnected ITADs to exchange all of the destinations they can reach, thereby acting in particular to facilitate the selection of the gateways that are the most appropriate for delivering IP telephony traffic to the PSTN. The TRIP protocol is implemented by location servers (LS) that propagate TRIP routes containing attributes that serve to describe the routes in question. The use of this particular protocol is independent of the type of signaling protocol deployed for actually setting up calls. The TRIP protocol can be used together with SIP, H.323, or any other signaling protocol. Each LS maintains a local routing database known as the telephony routing information database (TRIB). This routing database is fed with advertisements received from neighboring LSes (from another telephony domain, for example). The operation of the TRIP protocol is similar to that of the BGP protocol. Advertisements between neighboring LSes are made in the form of route update messages, referred to simply as update messages. These messages are defined by the TRIP protocol and they are exchanged between LSes in order to inform the LSes of the same domain or of a neighboring domain about routes that are available.
Activation of the TRIP protocol between various ITADs is described with reference to FIG. 1 (for reasons of simplicity, the term “domain” is also used to denote an ITAD), each ITAD being administered by a single IP telephony operator. Each of these operators has one or more LSes. Each LS maintains a routing database that it feeds with advertisements received from its neighbors (i.e. in other domains) and from LSes in its own domain. These advertisements are updated and forwarded to other neighbors when interconnection agreements permit this.
Thus, the LS of ITAD4 14, for example, updates the advertisements received from the LS of ITAD5 15 and re-propagates them to ITAD3 13. It should be observed that an ITAD is not necessarily deployed on a single AS or “IP transfer domain”.
From the routing point of view, an LS handles three types of route:                external routes, received from LSes situated in neighboring ITADs;        internal routes, received from LSes situated in the same ITAD; and        local routes, configured locally in each LS for injection into TRIP processes.This operation is performed either by static configuration or by redistributing information coming from other routing protocols.        
These routes are managed by the routing tables of a telephony routing information base (TRIB). Thus, four types of TRIB are managed by an LS, as is shown in FIG. 2. These tables exist in a single LS, and the relationship between the tables are described with reference to FIG. 2.                “Adj-TRIBs-In” 22: stores routing information conveyed by update messages. This routing information, also referred to as “routes”, constitutes the input to a route selection process 21 (decision process). A given LS maintains an adjacent TRIB-In table 22 for each neighboring LS in which it stores all of the route advertisements received from an adjacent LS;        “Ext-TRIB” 24: only one external TRIB table is maintained by an LS. This table contains the results of a route selection process applied to external routes 25 (Adj-TRIBs-IN) and local routes 26. Prior art techniques enable only one route to be selected per destination;        “Loc-TRIB” 20 (“local TRIB”): this table contains the local routes that result from applying routing policies that are local to each LS; and        “Adj-TRIBs-Out” 23 (adjacent TRIBs out): these are the routes that the local LS will advertise to its peers.        
In the transport layer, it is possible to use the QoS-enhanced border gateway protocol (q-BGP) in order to be aware of the QoS treatment to which the voice streams will be subjected by the transport layer.
2. Drawbacks of the Prior Art
A drawback of that prior art technique is associated with the lack of synchronization between the service layer and the network layer when routing media streams. In the context of deploying the TRIP protocol between neighboring ITADs, the media streams follow either the path determined by IP routing protocols such as the BGP protocol, or the path imposed by the telephony platforms of each ITAD. Routing within ITAD platforms requires the content of the SDP portion of messages to be modified several times, e.g. when using the SIP protocol.
A corresponding drawback of those prior art transfer techniques stems from the way ASes process media streams. Since such streams follow a path that is determined by the BGP protocol, the ITAD has no control over the path taken by the stream. Thus, it can happen that streams follow a path that is optimized within ITADs (e.g. for best QoS), but not at the level of paths between ASes. This can make the negotiations and the agreements between neighboring ITADs worthless if the QoS clauses are not satisfied.
In the context of a static configuration for the AS path to be followed by media stream, this possibility makes it necessary (e.g. in the context of using the TRIP protocol and while actually transferring streams) to modify the content of the SDP portion of SIP messages several times. This processing can lead to additional delays when it is necessary to pass through a plurality of ASes, and that can harm the quality of service as perceived by the final client.
Another drawback in that prior art technique is associated with the AS loop or spiral phenomenon. This AS spiral phenomenon is described with reference to FIG. 3.
An AS spiral occurs when, after negotiation between ITADs for routing a media stream, the stream passes more than once through a single AS prior to reaching its destination. Assume that ITAD1 311 uses AS1 321 to deliver its voice traffic, that ITAD2 312 uses AS2 322, that ITAD3 313 uses AS1 321, that ITAD4 314 uses AS4 324, that ITAD5 315 uses AS3 323, and that ITAD6 316 uses AS6 326. Also assume that the best route for reaching D 302 from S 301 is to pass via {AS1, AS4, AS5, AS6}.
Assume that a client S 301 seeks to place a call with D 302 and that ITAD1 311 selects a route passing via ITAD2 312 and ITAD3 313 in order to reach ITAD6 316 to which the destination D 302 is attached. This telephone level route assumes that there exists an IP route (in the transfer layer) passing through the domains: AS1, AS2, AS1, AS6. It can be seen that the call passes more than once through a single AS, specifically AS1. This constitutes a spiral at IP level and can be harmful to IP transfer performance since AS1 is passed through more than once. This phenomenon can nevertheless be avoided if the media streams follow the BGP path as opposed to the path imposed by the service platforms.
In order to illustrate this phenomenon once more, assume now that the path selected by ITAD1 for reaching D is {ITAD1, ITAD4, ITAD5, ITAD6}. This means that the AS path followed will be {AS1, AS4, AS3, AS6}. Unfortunately there is no direct link between AS4 and AS3. Thus this AS path becomes either {AS1, AS4, AS5, AS5, AS3, AS6} or else {AS1, AS4, AS1, AS2, AS3, AS6}. In either case, these paths are not optimum at IP transfer level and they are different from the paths selected by BGP.
Another drawback of that prior art technique is associated with the lack of synchronization between the service layer and the transfer plane. This phenomenon is described with reference to FIG. 4, in an IP telephony application.
It is assumed that ITAD1 is deployed on two ASes, AS1 and AS2, and that ITAD2 is deployed on the domain AS4, and that the two IP telephony operators managing the two ITADs, i.e. ITAD1 and ITAD2, have made an agreement for interconnecting their service platforms so as to extend the scope of their voice services with quality of service.
In order to deliver its voice traffic, ITAD1 relies on a premium class (i.e. a class that guarantees an IP transfer with a best quality of service, e.g. guaranteeing a loss rate of 99.999% and a maximum delay of less than 50 milliseconds (ms)) made available by AS1 and AS2; similarly, ITAD2 uses another premium class made available by AS4. At IP level, the IP network service providers exchange routing information to enable routes to be built up in QoS planes that are coherent and consistent. Thus, the premium class of AS4 is associated with the premium class of AS2 via a dedicated inter-domain route.
Thus, to reach C2 from C1, two best effort routes (i.e. routes available by activating a route protocol such as border gateway protocol (BGP) exist): the route that passes via AS1, AS2, and AS4, and the route that passes via AS1, AS3, and AS4. However only one premium route exists. This route passes via AS1, AS2, and AS4. To ensure coherent service, it is necessary for the voice traffic from C1 destined for C2 in the context of the telephony service made available by ITAD1 to use the premium route and not the best effort route. Unfortunately, unless a static configuration is implemented, there is no certain way for ITAD1 to ensure that it obtains a route passing via AS1, AS2, and AS4. Thus, it can very well happen, when media streams are actually transferred, that they pass via AS1, AS3, and AS4. This is due to the fact that the signaling protocol does not have a direct interface with the IP routing protocols that take charge of routing IP packets. Thus, the path of the signaling packets may be different from that of the media packets. Under such circumstances, the guarantees negotiated when setting up a call become obsolete.
In addition, those centralized and bilateral configuration techniques present the drawback of not satisfying coverage requirements since the number of agreements that need to be set up to provide global coverage becomes large.
What's more, bilateral agreements at service level are not sufficient for offering a quality of service. This is due to the fact that the quality of service perceived by the user also incorporates the quality of service delivered by the transfer layer. In order to make this mode viable, network operators must therefore set up IP connectivity agreements of the same kind, presenting the same level of quality of service. Unfortunately, given the large number of ASes (more than 17,000), such agreements cannot be put into place.